Software developers utilize conventional development tools that support the Unified Modeling Language (UML) for graphically modeling an object-oriented design of software projects. The well-known Unified Modeling Language (UML) is a general-purpose notational language for visualizing, specifying, constructing, and documenting complex software systems. UML is more clearly described in the following references, which are incorporated herein by reference: (1) Martin Fowler, UML Distilled Second Edition: Applying the Standard Object Modeling Language, Addison-Wesley (1999); (2) Booch, Rumbaugh, and Jacobson, The Unified Modeling Language User Guide, Addison-Wesley (1998); (3) Peter Coad, Jeff DeLuca, and Eric Lefebvre, Java Modeling in Color with UML: Enterprise Components and Process, Prentice Hall (1999); and (4) Peter Coad, Mark Mayfield, and Jonathan Kern, Java Design: Building Better Apps & Applets (2nd Ed.), Prentice Hall (1998).
These development tools use graphical notation to depict elements within the process or project being modeled. For example, a class diagram is typically used to describe both object (association) relationships and class (inheritance) relationships. The amount of detail presented on the class diagram depends on the development tool. Generally, a class diagram lists the name of the class, the class' important attributes, and the class' important methods. Related classes or objects of classes are denoted graphically by adding a graphical link notation to convey an inheritance, a single or bi-directional association (e.g., one object sends messages to another), or other relationships which add necessary complexity to the design when viewed as a whole.
Conventional development tools generally become difficult to use for complex models. As multiple classes are defined and multiple relationships are extended, the graphical representation becomes more of a burden. Faced with this problem, a software developer eventually will abandon the model as a system design development tool. For example, a developer looking to debug an existing design or to revise an existing model of a software program to conform to new requirements (e.g., new inventory scheme for suppliers) may become frustrated when viewing a detailed, complex model, and decide to debug or edit the source code directly. Typically, the developer will then add a patch of code that does not conform to good design practices rather then spend time understanding the complex graphical view of the model.
Conventional design tools that provide a graphical representation of code associated with modeling a business process or software project present an incoherent and unwieldy graphical view of the code when the respective model is complex. It is therefore desirable to simplify the graphical representation of software code in a modeling tool.